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The Multimission Three-Axis Stabilized Spacecraft (MTASS) Flight Dynamics Support 
System (FDSS) has been developed in an effort to minimize the costs of ground support 
systems. Unlike single-purpose ground support systems, which attempt to reduce costs by 
reusing software specifically developed for previous missions, the multimission support 
system is an intermediate step in the progression to a fully generalized mission support 
system in which numerous missions may be served by one general system. The benefits of 
multimission attitude ground support systems extend not only to the software design and 
coding process, but to the entire system environment, from specification through testing, 
simulation, operations, and maintenance. 

This paper reports the application of an MTASS FDSS to multiple scientific satellite 
missions. The satellites are the Upper Atmosphere Research Satellite (UARS), the Extreme 
Ultraviolet Explorer (EUVE), and the Solar Anomalous Magnetospheric Particle Explorer 
(SAMPEX). Both UARS and EUVE use the multimission modular spacecraft (MMS) 
concept. SAMPEX is part of the Small Explorer (SMEX) series and uses a much simpler set 
of attitude sensors. This paper centers on algorithm and design concepts for a multimission 
system and discusses flight experience from UARS. 


* This work was supported by the National Aeronautics and Space Administration (NASA)/Goddard Space Right Center 
(GSFC), Greenbelt, Maryland, Contract NAS 5-31500. 
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1. INTRODUCTION 

In 1987 the Upper Atmosphere Research Satellite (UARS) Attitude Ground Support System (AGSS) was 
being specified for Goddard Space Flight Center (GSFC). At this time the specifications support started for 
another mission, the Extreme Ultraviolet Explorer (EUVE). During the initial requirements analysis for 
EUVE. it was realized that UARS and EUVE were very similar in both hardware configuration and support 
requirements. The decision was made to generalize the UARS software specifications to include the EUVE 
support requirements. 

Flight Dynamics Division (FDD) attitude support falls into three categories: attitude determination, attitude 
sensor calibration, and prediction of flight dynamics-related parameters that are used for mission and science 
planning. A typical AGSS is composed of many functions, but can be broken down into six areas: telemetry 
processing, data adjustment, attitude determination, sensor calibration, sensor monitoring, and p lannin g aids 
prediction. 

Data come into the system as spacecraft telemetry. The telemetry processing function unpacks and tim e tags 
the data and passes them to the next function, data adjustment. Die data adjustment function corrects the data 
for known misalignments and biases and applies validation tests to reject bad data. The adjusted data are then 
ready for the attitude determination and sensor calibration functions. 

There is usually more than one attitude determination function to support different levels of accuracy and 
response time. Also, there is a sensor calibration function for each calibration parameter being computed. The 
attitude determination and sensor calibration results are usually delivered to the spacecraft control center for 
uplink to the spacecraft in support of onboard attitude determination. The sensor monitoring function is an 
analysis aid that supports sensor performance evaluations. 

The pla nnin g aids prediction function is a collection of functions for the production of mission and science 
planning aids. Some of these planning aids are mission-unique, but many are meant to meet similar 
requirements for a variety of missions. The common planning aids include guide star interference predictions, 
antenna contact times, spacecraft range predictions, and solar array position predictions. 

The multimission concept is an intermediate step in the progression to a generalized mission support system 
in which numerous missions may be served by one general system. Multimission systems are useful when 
generalized systems are not available or cannot be fully achieved. The benefits of multimission systems 
extend not only to the software design and coding process but to the entire system environment, from 
specification through testing, training, operations, and mainignafir* 

The Multimission Three-Axis Stabilized Spacecraft (MTASS) Flight Dynamics Support System (FDSS), 
referred to as MTASS in the remainder of this paper, is an institutional system that provides key functions 
required for spacecraft attitude ground support (see Reference 1). The AGSS for a specific mission is 
composed of mission-specific functions in combination with MTASS. 

2. SYSTEM DEVELOPMENT 

This section deals with the specification and design aspects of the MTASS systems development process. 

2.1 Specifications 

In the requirements analysis and functional specifications phase, the inherent commonality of the UARS and 
EUVE modular attitude determination and control systems influenced our approach. Since the EUVE AGSS 
was regarded, to first order, as a subset of the UARS AGSS, the UARS requirements and functional 
specifications were generalized to include the EUVE requirements. 
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During the generalization of the UARS specifications, it became clear that, with minimal extra effort, the 
specifications could be generalized much further than simply necessary to support two missions. During 
every step of the specifications support, ways were investigated to generalize the system as far as possible. As 
an example, spacecraft attitude is usually represented as a set of roll, pitch, and yaw angles with respect to 
some reference coordinate system. The most straightforward approach to producing a two-spacecraft system 
would be to specify an “If UARS...if EUVE...” type of construction to define the coordinate system. This 
method is obviously a dead-end that does not allow for other mission definitions. Instead, the specifications 
allow the user to specify the transformation Euler sequence and the reference coordinate system. This 
approach makes the system configurable and usable for any mission. Through this approach to 
generalization, MTASS was bom. 

To go beyond the reuse seen in previous ground systems, it was recognized that reuse on the subsystem level 
was required. Each of the functions described above have traditionally been implemented as separate 
subsystems; however, each subsystem was coded to be mission-specific with, at best, reuse of low-level 
software units. The MTASS concept was to organize the generic and mission-specific functions into separate 
subsystems, thereby allowing reuse of higher-level functions and entire subsystems. MTASS specified only 
generic algorithms for a given subsystem and thereby built up generic subsystems. Those algorithms that 
were unavoidably mission-unique were segregated into separate subsystems. 

2.2 Design Considerations 

This section reviews MTASS design considerations and shows that the design is sensor-oriented, MTASS is 
table-driven, the files are sensor-oriented, and the design is extensible. 

2.2.1 MTASS Design Is Sensor-Oriented 

The traditional functional approach to the design of MTASS was supplemented successfully with 
sensor/actuator-oriented thinkin g and software partitioning. Although object-oriented design techniques 
were not employed, the design partitioning was conceived with sensors as the design objects within each 
major functional partition (i.e., subsystem). The sensor-oriented partitioning lies along the intermediate level 
in that each subsystem contains software packages for each type of sensor and actuator appropriate to the 
subsystem function. 

For example, the data adjustment subsystem (DA) is a major functional partition that prepares the engineering 
data for attitude determination and other functions by applying calibration parameters (biases and 
misalignments), smoothing, and performing a few cross-sensor validation checks. The major portion of the 
DA is the application of calibration parameters. This function is partitioned by sensor type, resulting in a 
separate software package for the fine Sun sensor (FSS), the three-axis magnetometer (TAM)/magnetic 
torquer assembly (MTA), the inertial reference unit (IRU), etc. 

Table 1 contains an entry for each of the MTASS subsystems. Each entry includes the subsystem function, 
operating mode, and selectable subfunctions. 

2.2.2 MTASS Is Table-Driven 

Each MTASS subsystem has user-supplied configuration parameters that specify which sensors are present 
on a particular spacecraft, in a particular telemetry format, or needed for a particular operational scenario. 
Using these parameters, subsystems can be configured to support any three-axis stabilized spacecraft that 
contains a subset of the currently supported hardware and for which the engineering data are supplied in the 
MTASS formats. The one restriction is that IRU data are required for attitude determination using the MTASS 
coarse and fine attitude determination subsystem (CFADS), which employs a differential correction 
least-squares fit and uses body rates from the IRU data to propagate. This restriction will be alleviated when a 
new single-frame attitude determination subsystem, which employs the QUEST algorithm, is completed. 
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Table 1. MTASS Subsystems and Selectable Subfunctions (1 of 2) 


SUBSYSTEMS 

FUNCTION 

ATTITUDE DETERMINATION SYSTEM (ADS) EXECUTIVE 
(ADSEXEC) 

• ALLOW SELECTION OF INTERACTIVE ADS SUBSYSTEMS: 
MISSION SPECIFIC TELEMETRY PROCESSOR (TP), DA, 
STARID. DS, CFADS, DADS (ALSO OPERATES IN BATCH 
MODE) 

DATA ADJUSTMENT (DA) 

• APPLY MISALIGNMENTS AND/OR BIASES TO: 

(A) COARSE SUN SENSORS (UP TO 2 CSSs) 

(B) EARTH SENSOR ASSEMBLIES (UP TO 2 ESAs) 

(C) FIXED HEAD STAR TRACKERS (UP TO 2 FHSTs) 

(D) FINE SUN SENSOR (UP TO 1 FSS) 

(E) INERTIAL REFERENCE UNIT (UP TO 1 IRU) 

(F) THREE-AXIS MAGNETOMETER (UP TO 2 TAMs, 
OPTIONALLY INCLUDING EFFECTS FROM MAGNETIC 
TORQUER ASSEMBLIES (MTAs)) 

• OPTIONALLY SMOOTH BODY RATES FROM IRU 

• OPTIONALLY VALIDATE DATA USING DOT PRODUCT 
CHECKS 

STAR IDENTIFICATION (STARID) 

• USE TRIPLET, DOUBLET, SINGLE MATCH (STARID) 
HIERARCHY TO IDENTIFY STAR OBSERVATIONS FROM 
FHST AGAINST STAR CATALOG 

COARSE/FINE ATTITUDE DETERMINATION (CFADS) 

• DETERMINE SPACECRAFT ATTITUDE USING BATCH 
LEAST-SQUARES DIFFERENTIAL CORRECTION 
TECHNIQUE (NOTE: REQUIRES IRU) 

• PRECISION OF ATTITUDE SOLUTION IS DETERMINED BY 
SELECTION OF SENSOR DATA ADJUSTED BY THE DA 

• OPTIONALLY CALCULATE TAM BIASES 

• OPTIONALLY WRITE ATTITUDES AT AN EPOCH TIME 
AND/OR A SPECIFIED DELTA TIME, AND/OR WRITE 
ATTITUDE RATES AT THE SPECIFIED DELTA TIME 

DATA SEGMENTER (DS) 

• DETERMINE OPTIMUM/SUITABLE T1MESPANS TO ENSURE 
IRU DATA ARE AVAILABLE AND LOCATE FHST 
OBSERVATIONS NEAR BATCH BOUNDARIES FOR BEST 
PRECISION IN CFADS 

DEFINITIVE ATTITUDE DETERMINATION (DADS) 

• USE ATTITUDE PROPAGATION AND CORRECTION TO 
FORCE MULTIPLE SEQUENTIAL BATCHES OF CONTINUOUS 
ATTITUDES TO MATCH AT BATCH BOUNDARIES FOR 
CONTINUOUS ATTITUDES 

GRAPHICS USER INTERFACE (GUI) 

• ALLOW SELECTION OF INTERACTIVE CALIBRATION AND 
ATTITUDE VALIDATION SUBSYSTEMS 

• MAINTAIN AND REPORT CALIBRATION PARAMETERS FROM 
SENSOR CALIBRATION FILES 

• MANUALLY LOG AND REPORT MESSAGES IN ACTIVITIES 
LOG FILE(S) 

ATTITUDE VALIDATION (ATTVAL) 

• COMPARE PAIRWISE THE OBC-COMPUTED ATTITUDE, THE 
PREDICTED ATTITUDE, AND THE GROUND-DETERMINED 
ATTITUDE 

• EXAMINE ATTITUDES FROM INDIVIDUAL SOURCES 

INERTIAL REFERENCE UNIT CALIBRATION (IRUCAL) 

• CALIBRATE IRUs BY CONFIGURATION 

FINE SUN SENSOR, EARTH SENSOR. FIXED-HEAD 
STAR TRACKER CALIBRATION (FEFCAL) 

• CALIBRATE FSSs, ESAs. FHSTs 
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Table 1 . MTASS Subsystems and Selectable Subfunctions (2 of 2) 


SUBSYSTEMS 

FUNCTION 

FINE SUN SENSOR FIELD OF VIEW CALIBRATION 
(FSSFOV) 

. CALIBRATE FSS FIELD OF VIEW 

THREE-AXIS MAGNETOMETER CALIBRATION (TAMCAL) 

• CALIBRATE TAMS 

BATCH MODE SUBSYSTEMS 

• FOLLOWING SUBSYSTEMS ARE OPERATED IN BATCH 
MODE ONLY AND ARE INDIVIDUALLY SUBMITTED FOR 
EXECUTION 

(UARS) STS ATTACHED MONITOR (UMON) 

• GENERATE DISPLAY FOR CCTV DISTRIBUTION OF 
SPACECRAFT PARAMETERS INCLUDING ONBOARD 
ATTITUDE AND STS PARAMETERS DURING DEPLOYMENT 
FROM STS 

ATTITUDE PREDICTION (ATTPRED) 

• PREDICT ATTITUDES 

HIGH-GAIN ANTENNA, TDRSS CONTACT PREDICTION 
(HGA) 

• PREDICT POTENTIAL CONTACT TIMES BETWEEN HGA AND 
TDRSS 

GUIDE STAR OCCULTATION PREDICTION (GSOC) 

. PREDICT WHEN GUIDE STARS ARE OCCULTED BY THE 
EARTH, MOON, AND PLANETS 

ORBIT VALIDATION (UTEP) 

• CONVERT OBC-DETERMINED SPACECRAFT POSITION TO 
STANDARD CODE 500 EPHEMERIS FILE FORMAT FOR 
SUBSEQUENT COMPARISON WITH GROUND-DETERMINED 
AND PREDICTED ORBIT VECTORS USING INSTITUTIONAL 
SOFTWARE 

CALIBRATION DELIVERY FORMATTING (CALFORM) 

• SELECT AND CONVERT CALIBRATIONS FOR FORMATTING 
(ULTIMATE USE AS UPLOAD TO OBC) 

PRODUCT DELIVERY FORMATTING (DELFORM) 

• PACK DELIVERY RECORDS INTO STANDARD CODE 550 
PRODUCT DELIVERY FORMAT 


2.2.3 MTASS Files Are Sensor-Oriented 

Another crucial aspect of the MTASS design is the organization of the primary data interfaces. They are the 
engineering data sets data base (EDS), processed engineering data sets database (FEDS), attitude history files 
(AHFs), and sensor calibration files (SCFs). Table 2 contains a functional description of each of the major file 
types unique to MTASS. MTASS also uses the institutional spacecraft ephemeris, solar/lunar/planetary 
(SLP) ephemeris, activities log, report data base, MMS star catalog, and tracking station geodetics file types. 

The primary spacecraft data input to MTASS is through the EDS. The EDS is an MTASS-specific data base of 
spacecraft engineering data produced by a mission-specific telemetry processing (TP) subsystem. The EDS is 
a collection of engineering data sets tied together by an EDS directory data set. 

rarh indivi dual engineering data set contains batches of engineering data corresponding to one sensor or 
actuator. Each batch is user definable, but nominally corresponds to the data processed in one session from 
one telemetry transmission. The user can delete and overwrite the oldest batches, add new batches, or 
concatenate data to the most recent batch. The directory data set contains summary information for each 
batch, including which sensors are in the batch. 

The specific subset of engineering data sets included in a given EDS is definable by die user when that EDS is 
initialized. Further, the specific sub-subset of engineering data sets included in a given batch is definable at 
run time. Using these options, an EDS can be initialized that can contain data from only those sensors and 
actuators that are desired for a specific operational scenario using a specific spacecraft telemetry mode. 
Alternatively, an EDS can be initialized that can contain data from all of the sensors and actuators on a given 
spacecraft, and a given batch can contain data only for those sensors involved in a specific operational 

scenario. 
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Table 2. MTASS Data Sets 


SUBSYSTEM 


FUNCTION 

ATTITUDE HISTORY FILE 

• 

QUATERNIONS, EULER ANGLE RATES 

ENGINEERING DATA SET (EDS) DIRECTORY FILE 

• 

GENERAL DATA FOR EACH BATCH (HEADERS) 

EDS FSS 

• 

FSS ALPHA, BETA ANGLE COUNTS 

EDS ESA 

• 

ESA PITCH, ROLL ANGLES 

EDS FHST 

• 

FHST H AND V COUNTS AND INTENSITY 

EDS TAM 

• 

MAGNETIC FIELD VECTOR 

EDS IRU 

• 

IRU ACCUMULATED ANGLES 

EDS ANALOG IRU 

* 

ANALOG IRU RATE VECTOR 

EDS CSS 

• 

CSS PITCH, YAW ANGLES AND SOLAR PANEL ANGLES 

EDS HGA 

• 

HIGH-GAIN ANTENNA GIMBAL ANGLES 

EDSMTA 

• 

MAGNETIC TORQUER DIPOLE MOMENT VECTOR 

EDS RWA 

» 

ANGULAR MOMENTUM OF REACTION WHEELS 

EDS THRUSTER FIRING 

• 

THRUSTER FIRING COUNTS AND PULSE WIDTH 

EDS THRUSTER TANKS 

• 

THRUSTER TANK TEMPERATURES AND PRESSURE 

EDS OBC EPHEMERIS 

• 

OBC-DERIVED SPACECRAFT POSITION AND VELOCITY 

PROCESSED ENGINEERING DATA SET (PEDS) 
DIRECTORY FILE 

« 

GENERAL DATA FOR EACH BATCH (HEADERS) 

PEDS FSS 

« 

OBSERVED SUN UNIT VECTOR 

PEDS ESA 

• 

OBSERVED EARTH UNIT VECTOR 

PEDS FHST 

• 

OBSERVED STAR UNIT VECTOR, REFERENCE STAR UNIT 
VECTOR, AND STAR MAGNITUDE 

PEDS TAM 

• 

OBSERVED MAGNETIC FIELD VECTOR 

PEDS IRU 

• 

OBSERVED BODY ROTATION RATES 

PEDS CSS 

• 

SUN UNIT VECTOR AND SOLAR PANEL ANGLES 

ESA SENSOR CALIBRATION FILE (SCF) 

• 

ESA ALIGNMENT AND BIAS 

FHST SCF 

• 

FHST ALIGNMENT 

FSS SCF 

• 

FSS ALIGNMENT AND FOV CALIBRATION 

IRU SCF 

• 

IRU ALIGNMENT, SCALE FACTOR, AND BIAS 

TAM SCF 

• 

TAM ALIGNMENT, SCALE FACTOR, AND BIAS 

HGA G1MBAL MASK FILE 

• 

FILE DEFINING HGA MASK 


Most of the attitude determination-related engineering data contained in an EDS are processed by the DA, 
which produces the PEDS. The PEDS are organized like and contain the same selectivity as the EDS. One 
significant feature specific to the PEDS is the commonality of data representation. For each appropriate 
sensor type in the PEDS, the processed engineering data are represented as a vector. The PEDS are the most 
central data storage point for the MTASS. PEDS batches are created by the DA. Numerous subsystems obtain 
data from the PEDS, although a few use EDS data directly. 

Each batch of PEDS data contains the complete set of calibration parameters applied to that data. The DA 
obtains these calibrations from the SCFs. One SCF exists for each type of sensor. Each SCF can contain the 
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calibration parameters for up to 10 of that sensor type. For each sensor represented in an SCF, a complete 
history of calibrations can be maintained. Additionally, the current default set of calibration parameters for 
each sensor is marked for easy retrieval by the DA, and every past default set of parameters is identified as 
such. 

When the DA retrieves a set of cal ibration parameters , the current default can be selected, or the user can selec t 
the desired set from a list of all sets for the specific sensor in question. A separate maintenance function also 
exists that allows the user to delete obsolete sets of calibration parameters and change the default set. 

At several points in MTASS the spacecraft attitude is written to an AHF. The onboard computed (OBC) 
attitude can be written from the mission-specific TP, the coarse or fine attitude is written from the CFADS, 
and a definitive attitude series is written from the definitive attitude determination subsystem (DADS). 
Additionally, the CFADS can optionally write attitude rates with or without the accompanying attitudes. 

The MTASS AHF was defined as a new standard file for storing attitude information. The attitude is stored as 
a quaternion in the geocentric inertial (GO) frame. The attitude rates are stored as angular rates about each 
spacecraft body axis. The data on an AHF are stored in batches. Each batch has a set of header records, 
optionally followed by a series of attitude data records. The header records contain an optional epoch attitude 
quaternion and an optional epoch spacecraft orbit vector. The attitude data records in a given batch can contain 
at t itu d e quaternions, attitude rates, or both. 

The concept of generalized data structures was also applied to the definition of delivery file formats for 
planning aids. If the delivered product is the same for each mission, there is no need for a different software 
system. The FDD negotiated with other NASA/GSFC ground support elements for the acceptance of 
generalized file formats as standard FDD products. This standardization has been most successful for 
planning aids. 

MTASS uses the well defined GSFC Code 500 standard ephemeris (EPHEM) file format for spacecraft 
position vectors, and the SLP ephemeris file for positions of the Sun, Moon, and planets. 

As is traditional in GSFC Code 550 flight dynamics software, the FORTRAN NAMELIST technique is used 
for all user-definable configuration and control parameters. The NAMELIST files allow the user to override 
the hard-coded default values. These NAMELIST files are created or modified prior to the time of execution 
of MTASS. NA MELI ST files can be set up for each operational scenario for each spacecraft to define each 
needed configuration. Most configuration and control parameter values can also be modified at execution 
time for those subsystems containing an interactive user interface. 

2.2.4 MTASS Design Is Extensible 

The list of sensors supported by MTASS can be extended through enhancement development efforts. The 
spacecraft hardware currently supported by MTASS was defined by the needs of UARS. The sensor-oriented 
design in MTASS, however, allows for the addition of other sensor and actuator types. Each appropriate 
subsystem would be modified to add a new software package to process data from the new hardware type, and 
corresponding configuration and control parameters would be added. 

An alternative approach was employed for the Solar, Anomalous, and Magnetospheric Particle Explorer 
(SAMPEX) spacecraft. The SAMPEX hardware was similar, but different from that supported by MTASS. 
Consequently the SAMPEX telemetry processor (TP) contained special processing to convert the SAMPEX 
digital Sun sensor (DSS) data to comply with the MTASS FSS EDS format. The SAMPEX coarse Sun sensor 
(CSS) arrays were processed to produce MTASS CSS EDS data. Finally, SAMPEX does not contain an IRU, 
so the SAMPEX TP calculates body rates to store in the MTASS IRU engineering data sets (which are needed 
by the CFADS to propagate attitudes). Finally, the SAMPEX attitude needs to be reported in a special 
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Sun-based reference frame, so the SAMPEX AGSS contains an attitude postprocessor that converts the 
MTASS attitudes from the AHF into the desired form. This SAMPEX AGSS is a good example of building a 
relatively small amount of extra processing in the front and back of the system in order to reuse entire MTASS 

subsystems. 

3. FLIGHT EXPERIENCE WITH MTASS 

At present, flight experience with MTASS consists primarily of experience with UARS, although some 
prelaunch spacecraft telemetry processing experience is now available from EUVE. Our discussions of 
MTASS flight experience are thus primarily directed to the UARS mission (see Reference 3). 

UARS flight experience with MTASS can be divided roughly into no minal behavior and non-nominal 
behavior. Although the bulk of mission events to date fall into the class of nominal behavior, and although 
MTASS has performed in most respects like any other attitude support system created for the Mission 
Operations and Data Systems Directorate (MO&DSD), such non-nominal behavior as has been observed to 
date is reviewed here with the objective of identifying any features of this behavior that could be traced to the 
multisatellite character of MTASS. Our finding is that the non-nominal behavior was not attributable to the 
multisatellite character of MTASS. 

Areas of nominal behavior with MTASS identified to date in the UARS mission experience include the 
following: 


Behavior 

Generating and transmitting PDF products 
Prelaunch readiness testing 

Monitoring UARS attitude 
Monitoring solar array release 
Monitoring HGA deployment 
Fine attitude determination 

Monitoring UARS release 
TAM bias determination 
Observing solar array thermal snap 
IRU bias determination 
Monitoring ascent maneuvers 
Monitoring yaw maneuver 
Monitoring roll maneuver 
Monitoring orbit adjust 
Preliminary OBC validation 

An example of MTASS nominal behavior is found in the results of OBC validation. Ground solutions for roll, 
pitch, and yaw angles, including corrections for all known calibration errors, were determined from 
91 1028.01 50 to 9 1 1028.0328, with an estimated uncertainty of less than 10 arc-seconds in each of the angles. 
The root-mean-square differences of the OBC and the ground angles over this interval were found to be 8 
arc-seconds in roll, 21 arc-seconds in pitch, and 5 arc-seconds in yaw. At all times the OBC knowledge was 
within the required 60 arc-seconds. The root-mean-square differences between ground solutions and the 
desired or target attitudes over this interval were 35 arc -seconds in roll, 41 arc-seconds in pitch, and 34 
arc-seconds in yaw. The differences, which are a measure of the accuracy of OBC control, were at all times 
within the required 108 arc-seconds for pitch and yaw. The roll angle accuracy exceeded the requirement 


Phase 

Prelaunch 

Launch to Release 
Early Mission 
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approximately 1 percent of the time and is related to the solar snap phenomenon. The good agreement of 
ground-determined attitudes, OBC-determined attitudes, and control attitudes provides an excellent example 
of the nominal performance of the combined MTASS and flight systems. 

Areas of non-nominal behavior with MTASS identified to date in the UARS mission experience include the 
following: 


Phase Behavior 

Launch to Release TP timing problem 

Early Mission FHST attitude propagation problem 


The telemetry processing problem consisted of errors in unpacking data when a UARS minute boundary was 
being crossed. The problem was traced to a requirement to handle data gaps of any length of time. A 
workaround was developed to remove the original calculation of the UARS minute counter and replace it with 
calculations dependent on the engineering minor frame counter. 

The fixed-head star tracker (FHST) attitude propagation problem was manifested by several symptoms: the 
star clumps were spread out, the residuals were high, and the attitude solution did not match the OBC 
solution. The problem was traced to an erroneous counts-to-angles field-of-view (FOV) scale factor in the 
FHST. 

Neither of the problems discussed above arose from the innovative multisatellite features of MTASS, they 
could have arisen in any system. On the whole, MTASS performance with UARS was as good as or better than 
experienced with previous ground systems. 


4. BENEFITS 

Multimission flight dynamics ground support systems like MTASS are being developed to achieve 
significant cost reduction. Unlike single-purpose ground systems, which achieve a much lower level of reuse 
and thus a lower level of cost saving, the multimission attitude support system is an intermediate step to a 
generalized system in which numerous missions are served by one general system. The benefits of 
multimission attitude ground support systems extend not only to the software design and coding process but 
to the entire system environment, from specification through testing, simulation, operations, and 
maintenance. 

4.1 Benefits for Specifications 

As described in Section 2.1, there were significant advantages to raising the level at which reuse occurred 
from low-level reuse to subsystem reuse. Thus, entire areas of functionality were generalized. The benefit is 
that specifications do not need to be reworked at such a fine level of detail for each new satellite. Additional 
benefits were realized by segregating mission-specific algorithms into separate subsystems. 

4.2 Benefits for Software Design and Coding 

The cost of software development from the software design phase through the acceptance testing phase is 
strongly related to the size of the system, where the cost for verbatim reused software is approximately 
20 percent of the cost of newly developed software. The cost to develop AGSSs for EUVE and S AMPEX has 
been greatly reduced by reusing MTASS. Based on this success, the development of the Total Ozone Mapping 
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Spectrometer (TOMS) AGSS has begun and similarly plans to satisfy significant major functions with 
MTASS. Additionally, plans are being made to base the AGSSs for the International Solar-Terrestrial Physics 
(ISTP) Solar and Heliospheric Observatory (SOHO) and X-ray Timing Explorer (XTE) missions on MTASS. 
Using the relationship between software development cost and system size, the relative cost savings for 
EUVE and SAMPEX can be inferred from Table 3. This table shows total source lines of code (SLOC), new 
SLOC, and reused SLOC for UARS, EUVE, and SAMPEX. The reused SLOC for EUVE and SAMPEX is 
primarily reused from MTASS. The reuse for UARS is primarily existing utility packages. 

Table 3. System Size for AGSSs Using MTASS 


MISSION 

TOTAL SLOC (K) 

NEW SLOC (K) 

REUSED SLOC (K) 

UARS 

335.4 

294.8 

40.6 

EUVE 

273.5 

48.8 

224.5 

SAMPEX 

176.1 

24.1 

152.0 


Note: Size is measured in 1000 SLOC. 


4.3 Benefits for Testing, Simulation, Operations, and Maintenance 

UARS and EUVE combined acceptance testing provided a good example of test systems that could not only 
benefit from a high degree of commonality but could be operated in a single test environment. That is, from 
the beginning UARS and EUVE testing was conceived and implemented by a single acceptance testing 
process group. Personnel already familiar with the pattern of UARS tests readily adapted to requirements for 
EUVE-specific tests and readily applied the techniques and methods that had proved successful for UARS 
tests also to EUVE tests. Thus, methods of test evaluation and scoring, test tracking, and scheduling used for 
UARS could be adapted almost without change to EUVE. 

In a manner similar to testing, the high requirements and software commonality for UARS and EUVE 
exhibited by MTASS supported the simulation phase. Thus, personnel already familiar with the setup and 
conduct of UARS mission simulations quickly adapted their methods and skills to the generation of EUVE 
simulations. On the other hand, the MTASS system, as adapted to UARS, or, alternatively, EUVE, with 
mission-specific job control language (JCL) and input data, tended to diverge with time, thus diluting some of 
the benefits observed during the earlier stages of the cycle. 

Similarly, the entry of the mission-tailored systems into the operations phase tended to further dilute some of 
the benefits because of differences in the details of mission operations support; for example, differences in the 
single. Earth-pointing control mode of UARS and the multiple, survey and inertial-pointing modes of EUVE 
were reflected in the number and frequency of predictions required for the two missions. Moreover, the 
intensified effort and staffing peak required by the actual launch and deployment of UARS tended to compete 
with an ongoing demand for EUVE support and resulted ultimately in separate management arrangements for 
UARS and EUVE flight dynamics support. 

The benefits accruing to maintenance from multisatellite systems like MTASS follow from the fact that 
corrections and enhancements originating from experience with one satellite, say UARS, usually apply to the 
other satellite, say EUVE. In this way, maintenance effort is streamlined. 

5. ISSUES 

Our experience with developing and implementing a three-axis stabilized multisatellite flight dynamics 
support system raises several issues. These issues concern performance, testing, maintenance, and 
configuration management. 
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5.1 Performance Issues 

The increased generality in some MTASS algorithms results in some increased execution time and memory 
requirements for some program steps. The necessary provision of some mission-specific modules for severa 
satellites in MTASS could also increase code storage requirements. In practice, the actual savmgs are 
determined by competition among conflicting trends. For MTASS, the execution time of some program steps 
has not been as small as desired; for example, under certain cooditions attitude detemmiauon has not occuired 
in near-real time. Moreover, the MTASS code storage requirement, measured m numbers of SLOC, has been 
larger than for previous systems, but is offset by the need to store only one copy of the MTASS code. 

5.2 Testing Issues 

Another issue concerning MTASS is whether, and to what extent, the benefits of a midtisatellite capabihty 
that were realized in the specification and development phase extend also to the testing phase. It is well known 
that testing can address only a small subset of the total number ol possible paths through the software system, 
consequently the question arises whether test cases generated for one satellite in the mulhsatellite system are 
representative of the program paths that will be used for all satellites, or whether test cases specific to every 

satellite must be used. 

About 80 percent of MTASS consists of requirements and software common toUARS and EUVE. Thus, the 

were unnecessary and redundant. In this way, significant economies were realized in the combined 
acceptance testing of the multisatellite system. 

In the 20 percent of the system where no overlap existed, separate UARS- andEUVE-specific test cases were 
executed. For example, in the case of antenna contact predictions, the EUVE case mvolved test cases in two 
control modes (survey mode and inertial pointing mode), whereas in the UARS case only one control mode 
(Earth pointing) was tested. 

The common pathway approach was also utilized in the acceptance testing of the UARS ^dEWE teleme^y 
simulators, which served as test drivers for the telemetry processing programs used with MTASS. Although 
the telemetry processing programs are not considered part of MTASS proper, it is nonetheless ms trative to 
consider the approach used. Although a single, multisatellite telemetry simulator might have been desirable 
in fact a separate EUVE telemetry simulator was developed through a high degree of reuse of the UAR 
simulator In testing the EUVE simulator, it was found possible in some cases simply to operate the simulator 
with UARS input and identify the expected results with the corresponding output from a previously accepted 

UARS simulation. 

Apart from the benefits to testing that accrued from a large UARS/EUVE requirements and software 
commonality, a common management structure fully exploited the potential benefit of a mulasateUite 
development environment. The acceptance testers, test coordinators, and task leaders for the testing of both 
satellites belonged to a single administrative unit under a single manager. This arrangement followed through 
on the promise and potential of the multisatellite approach and achieved significant economies and effic lency. 

5.3 Maintenance Issues 

Issues connected with the maintenance of multisatellite ground support systems are potentially more severe 
than issues connected with acceptance testing. The reason is that the maintenance phase of the software 
development life cycle is closer in time to the actual satellite launch, when the multisateUite system is more 
fully adapted to the idiosyncrasies of each satellite. For example, product delivery requirements and data set 
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size requirements dictated different tailoring of associated software, such as JCL and command lists 
(CLISTs), for EUVE than for UAJRS. Thus, as the fully adapted systems approach satellite launch, the 
systems tend to diverge in detail and the maintenance efforts tend to lose the benefit of overlap. Moreover, 
because of the high concentration of effort with the approach of launch and the existence of separate project 
teams for the different satellites, there is pressure for separate, dedicated launch support organizations to 
form, and with this development some of the benefits of a common management structure may be lost. In the 
case of UARS and EUVE, however, we were fortunate to have the same nucleus of software maintenance 
personnel for both satellites in the critical prelaunch maintenance phases, thus simplifying our efforts. 

5.4 Configuration Management Issues 

MTASS is maintained under a single configuration management structure and changes originating from one 
satellite or another are managed as a general case. Moreover, changes are instituted simultaneously without 
regard for the fact that in practice one satellite will go to the launch phase before another satellite. 

Configuration management issues arise from several sources. For example, the need for change may arise 
first in, say, a UARS launch simulation and pressures of time and budget may tempt implementation of the 
change in a way that is not at first sufficiently general to cover EUVE and SAMPEX. Or, a EUVE simulation 
may uncover the need for a change that can impact the already-launched UARS, but the routine operations 
organization for UARS may prefer to defer the change. For reasons such as these, the configuration 
management of MTASS raises issues that do not arise in conventional single-satellite systems. 

6. TRENDS 

As mentioned above, plans are in place to use MTASS to satisfy significant major functions for the flight 
dynamics support of TOMS, ISTP SOHO, and XTE. Other potential missions to reuse MTASS will be 
examined. The one major limitation of MTASS is that the spacecraft be three-axis stabilized. Since there is 
lately a resurgence of spin-axis stabilized spacecraft with the ISTP/Global Geospace Science (GGS) Project 
Interplanetary Physics Laboratory (designated WIND) and Polar Plasma Laboratory (designated POLAR) 
missions and the SMEX-2 Fast Auroral Snapshot Telescope (FAST) mission, the usefulness of a 
multimission FDSS for spinning spacecraft was recognized. Consequently, the mul timi ssion spin-axis 
stabilized spacecraft (MSASS) FDSS was bom (see Reference 2). It is currently completing development to 
support both WIND and POLAR, and plans are in place to satisfy significant major functions for the SMEX-2 
FAST mission. 

The trend to use MTASS and MSASS for upcoming missions will continue until a more g eneralized mission 
configurable system replaces them. 
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